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SECURE FORWARDING SYSTEM 

Field of the Invention 

The invention relates generally to computing systems and more particularly to a 
method and system for providing secure data transmissions between Internet users. 

Background of the Inventinn 
The Internet is a global network of computers tiiat uses a common commimication 
protocol, the Transfer Control Protocol/Intemet Protocol (TCP/IP), to transmit data from 
one location to another. Many application specific tasks, such as E-mail transmission and 
file transfer, are not directly supported by TCP/IP. Instead, support for these services is 
implemented by application specific protocols that in turn rely on TCP/IP for basic data 
transport services. One problem that is relatively unknown to individuals that make use 
of the internet is the ease by v^ch information can be obtained during transmission by 
unauthorized eavesdroppers. For example, most E-mail transmissions over the Internet 
are sent in cleartexL Cleartext is imenciypted data that can be intercepted anywhere along 
the path between a sender and the recipient 

Accordingly, sensitive business or personal information should not be transmitted 
in cleartext over the Internet. To do so is to risk its publication. To avoid this risk, 
sensitive data is often sent by courier services or other means at great cost 

Encryption mechanisms can be used to ensure the integrity of infonnation sent 
over the Intemet Two common encryption techniques, symmetric key encryption and 
public key encryption, are described below. In a symmetric key encryption, a unique key 
is identified and used by the sender to encrypt and by the receiver to decrypt a message. 
In public key encryption, separate keys are used to encrypt and to decrypt. 

Both symmetric key and public key encryption require a key exchange. That is, 
where qrmmetric key oicryption is used, the sender must provide the recipient with the 
key so that the recipient can decrypt an associated message. In public key encryption, the 
key exchange includes the publication of a recipient's public key that in turn is used by 
the sender to encrj^t a message. A corresponding private key is used by tiie recipient to 
subsequently decrypt the encrypted message. Publication can be by posting the public 
key, for example, to a central site, or by providing the public key directly to the sender. 
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If a preference for delivery other than Web-based is specified, the system delivers the 
message in accordance with the recipient's preference. 

Implementations of the invention can include one or more of the following 
advantages. 

Messages can be encrypted using any available encryption means at tbe sender and sent to 
a forwarding service. The forwarding service can forward the message to each recipient 
according to the recipient's decryption capability and preference.. 

A system is provided for secure E-mail services. Secure E-mail messages can be 
composed or generated using the secure messaging system (using a particular encryption 
service), the result of which can be attached as a MIME or SMIME message to a 
conventional E-mail message for transfer to a recipient In the event the recipient does 
not have the required decryption capabilities, the E-mail message can be forwarded to a 
forwarding service. Hie forwarding service provides an E-mail notification to the 
recipient of the message. A recipient is not required to have a special viewer or reader 
and can merely retrieve the message through a web browser by linking to the forwarding 
service via a secure link such as SSL. Alternatively, if the recipient has designated a 
preference for delivery, the message can be re-encrypted according to the recipient's 
preference and delivered to the recipient directly in accordance with the predefmed 
delivery instructions. 

These and other advantages of the present invention will become apparent fiom 
the following description and from the claims. 

Brief Des CTiption of the Drawing s 
Figure la is a schematic block diagram of a computing network for faciUtating a 
secure data exchange. 

Figure lb is a schematic block diagram of an operational perspective of the 
forwarding service of Figure la. 

Figure 2a shows a generalized process for securely sending and receiving 
encrypted E-mail over a network. 

Figures 2b.2e show a flow diagram for a method of exchanging E-mail securely 
over a network between a sender and a recipient 
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^Climt" refers to a computer program that, among other iunctioias, requests 
s«-vices from a server and more generally as the computer that runs a client program or a 
browser. Here, a client program includes a communication program for sending electronic 
messages (such as E-mail) to other clients through a network, or for interpreting messages 
from other clients. 

"Server" refers to a computer program that provides services to clients, and more 
generally refers to a computer that runs a server program. "Key server" refers to a 
computer that includes a server program for maintaining, validating and distributing 
public keys for use by clients in transmitting secure E-mail or other messages over a 
network. 

"Exchange" refers to a commimicadon between a client and a server over a 
network The exchange occurs along a connection path between client and server and 
includes a request (generated by the client) and a response (from the specified server). 
Requests and responses can be generated by each of the client and server depending on 
the exchange. 

"Secure transmission" or "secure E-mail transmission" refers to a seciire 
commimicadon between two endpoints over a network. Such a conmiunication can be 
highly secure and include a wr^per, an encrypted message, a signature, and a time stamp 
certificate. Alternatively, the communication can have minimal security and include only 
a wrapper and a link to a message that is secured by using a transmission protocol (e.g., 
secure socket layer (SSL)) between devices. The wrapper can be received by a recipient's 
conventional E-noiail service. The message (and otiier information e.g., signature and time 
stamp) can be recovered (and verified) by the recipient by invoking a secure message 
viewer at the recipient client computer or through a web browser. 

'"Network" refers to a private or public network. Private networks include an 
intranet, that is, a network connecting one or more private servers such as a local area 
network (LAN). Alternatively, the network can be a public network, such as the Internet, 
in which data is passed over non-secure communication links. The network configuration 
can include a combination of public and private networks. For example, two or more 
LAN's can be coupled together with individual terminals using a public network such as 
the Internet 
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Referring now to Figure 1, an interconnected computing system 100 for 
&cilitating c ommun ication between two or more client computers (e.g., a '^sender" 102 
and one or more "recipients" 104) over network (Internet) 106 is shown. A key server 
108 is also coupled to network 106 and can be accessed by the sender 102 and one or 
more recipients 1 04. One or more key retrieval servers 1 80 are also coupled to network 
106 and can be accessed by any of sender 102, recipient 104 and key servers 108. The 
key retrieval server 1 80 and key server 108 can be sq)arate servers or can be combined. 
A trusted third party server 1 90 can be coi5)led to key server 1 08 through a direct 
connection 192 or a secure Internet connection through network 106. Finally, a 
forwarding service 195 is coupled by a secure or non secure Intemet connection through 
network 106 to sender 102 and one or more recipients 104. 

Sender 102 and recipient 104 each include an operating system 120 and one or 
more applications 122 executing on the client computers. Recipients 104 can be of two 
classes: fully configured recipients 104a and minimally configured recipients 104b. 

Minimally Configured Recipients 

Minimally configured recipients 104b include a web browser application 123 that 
supports a secure communication protocol (e.g., SSL) for accessing the Intemet and 
receiving and viewing minimally secure messages transmitted by the sender 102 and 
forwarded by forwarding service 195 to the minimally configured recipient 104b. In 
addition, minimally configured recipients 104b include an E-mail application 126 for 
receiving notices fi-om forwarding service 195 that a message is available to be reviewed. 

Web browser application 123 can be an Intemet browser program (referred to 
herein as a "browser'') such as NETSCAPE NAVIGATOR®. The customer can direct 
the browser to a web site associated with the forwarding service 195 and render or 
download a message firom a server hosting the web site. The minimally configured 
recipient 104b can be implemented as a browser-based system in accordance with the 
standard protocols for communicating over the Word Wide Web, including SSL support 
In such an implementation, a user of the minimally configured recipient computer 104b 
can execute browser application 1 23 to connect to and interact with the forwarding 
service 195. Forwarding service 195 includes a web fiont end 191 Ihat manages the 
communications with the client computer (such as recipient 104b) . The user of the client 
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secure messages to a recipient using forwarding service 195. The processes of signing, 
enciypting and forwarding a message are described in greater detail below. 

Viewer 130 can be called from E-mail application 126 and used to view a secure 
E-mail transmission. Viewer 130 includes a verification process 152 and decryption 
process 156. Decryption process 156 decodes encrypted messages produced using 
encryption process 154. After decryption, verification process 152 can be invoked to 
authenticate signatures produced using signing process 150. In one implonentation, 
wrapping ^plication 128 and viewer 130 are bundled in a single application. 

Signature manager 132 is a utility for managing racryption keys for a user. Prior 
to the use of wrapping application 128 or viewer 130, each user (e.g., sender 102 or fiilly 
configured recipient 104a) must generate public and private keys. Signature manager 132 
includes methods for generating public and private keys. Signature manager 132 submits 
the public key to key server 1 08 for publication. Key server 1 08 publishes the public keys 
in a key list which in tum can be distributed to key retrieval servers 1 80. Signature 
manager 132 can be used to create new keys, change keys, delete keys or change signature 
phrases. Signature manager 132 includes key process 160 for creatmg and storing private 
and public keys for use in transmitting highly secure E-mail. Signature manager 132 
stores a user's private key(s) in a key file 133. Key file 133 may contain a plurality of 
keys stored for one or more E-mail addresses. The key file 133 may be transferred from a 
user's computer to another computer to allow a user to send and receive secure E-mail 
messages on a computer other than the computer used to create the private key. The 
private key can be encrypted using a symmetric key derived from the signature phrase. 
Only persons having the correct signature phrase can recover a user's private key. 
Signature manager 132 can also be bundled into another application. 

Network 106 can be the Internet, an intranet or a combination of public and 
private networks. 

Key server 1 08 can be a server computer executing one or more server programs. 
Key SCTver 108 includes one or more server applications executing on the server computer 
and includes an operating system 200, key exchange application 202, HTTP post and 
forwarding proxy server application 204, recovery application 206, key list 208, status list 
209 and trusted third party (TTP) ^plication 210. , In one implementation, key server 108 
and key retrieval server 1 80 are the same server. 
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HTTP post and forwarding proxy server ^plication 204 provides an easy means 
of transmitting messages without requiring a sender to have access to a SMTP server or 
other communication server. The HTTP post application m the client plication sends 
the secure message by an HTTP post me&od to a forwarding proxy. In one 
implementation, key server 108 includes an HTTP post and forwarding proxy server 
application 204 which is used to recover the secure message (still secured) from the 
HTTP post and forward or otherwise relay the message as an attachment to a conventional 
E-mail message. In one implementation, a plurality of dedicated forwarding proxy servers 
are provided, each separated from the key server, where flie number is set based upon 
system requirements. 

Recovery appUcation 206 is invokai by a user (sender 102 or recipiait 104) and 
supports the recovery of the private key of the user in the evait flie private key is lost or 
the signahire phrase is forgottm. 

Key list 208 is a repositoiy for public keys. In one implementation, public keys 
are mdexed by the owner's E-mail address and the hash of the E-mail address. A public 
key can be retrieved by submitting either the E-mail address or the hash of the E-mail 
address for the recipient (or the sender, depending upon the pubUc key to be retrieved). A 
public key (PK) for the recipient is retrieved at the time a secure E-mail message is 
created. 

Trusted Aird party application 210 &cilitates the transfer of private keys of users 
to a trusted tfafrd party. Trusted third party application 210 is described in greater detail in 
"Secure Messaging System." 

Each of key retrieval servers 180 can be a server computer executing one or more 
server programs. Each key retrieval server 180 includes one or more server applications 
executing on the server computer. Key retrieval server 180 includes an operating system 
120, a key exchange appUcation 202, key Ust 208, status hst 209 and list update process 
1 82. In one implementation, key server 1 08 is a centralized server that maintaing a master 
key Ust and status Ust that are pubUshed to each of the key retrieval servers 180. As such, 
key exchange application 202 can be removed from the central server (key server) and 
distributed to one or more local key retrieval servers 180. list vpdabs process 182 
inter&ces wi& key server 108 to maintain current key and status lists. Key retrieval 
server 1 80 can also include forwarding proxy services 1 84 for forwarding HTTP posts 
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The processing in filter layer 193 may include parsing, decryption and 
authentication services as well as other services. Ths filter l^er 193 consists of several 
filter units each dedicated to process secure messages sent by a particular type of sending 
appUcation. In one inq)lemeniation. filter layer 193 includes a ZixMail unit, a PGP unit, a 
web-based compose form unit,and an X.509 S/MIME unit Other filter units can be added 
to the filter layer 193 as required to support other messaging formats. Regardless which 
filter unit of the filter layer processes an inbound message, the resulting output of filter 
layer 1 93 is always in a standard format and can be rendered to the recipient in the same 
fashion. This solves the long-standing interoperabiUty problem of different secure emafl 
programs. 

Each filter unit in the filter layer supports a particular messaging format. A unit 
may support decryption, parsing, authentication and other services as appropriate for tiie 
message format For example, a ZixMail unit may be configured to decrypt a received 
ZixMail message using a private key of the forwarding service 195, authenticate the 
sender and message contents using an authentication routine, and parse tiie decrypted 
message to create a standard format message. 

In one implementation, the standard format message data structure includes 
authentication data and message data (authentication block 502 and data block 504, 
respectively). The authentication data can be provided &om the sender or developed as a 
result of processing by tiie filter layer 193. For ekample. tire autiientication data can be 
tiie result of tiie verification process for a digital signaftire. Alternatively, tiie 
autiientication data may be tiie result of a sender provided autiientication pass phrase. The 
standard format messages are securely stored in queue stiiicttire 197 until retiieval or 
otiier predefined criteria is encountered. Predefined criteria can include tiie passage of 
time or a removal notice &om the sender. 

Queue stiiicture 197 includes a storage area for messages tiiat may be refaieved 
using a web browser or otiier means by an intended recipient In one implementation, tiie 
queue structure 197 includes a message area and an index area. Associated witii each 
message (standard format message) is an index. The index can be used in a hyperlink tiiat 
is forwarded to tiie intended recipient to identify tiie message. Tlie generation of tiie 
hyperlink is described in greater detail below. In one implementation, filter layer 193, as 
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pass phrase or RAPP and a send authorization pass phrase or SAP?). Each entry in the 
access list 199 includes an identifier and a SAPP and/or RAPP. The creation of an 
authorization pass phrase (S APP/RAPP) is described in greater detail below. In one 
implementation, the forwarding engine receives a page request from the web front end 
191 that includes an authentication pass phrase from the recipient (a receive authorization 
pass phrase or RAPP). The RAPP can be verified prior to returning the web page 
including the message to the recipient The creation of a RAPP is described in greater 
detail below. 

The access list 199 may also include user preference data The user preference 
data may specify an encryption/decryption protocol to be used by the forwarding service 
195 when forwarding messages to the user. For example, when a message is received for 
an intended recipient, forwarding engine 198 may check the preference data associated 
with the intended recipient in the access list 199 to determine how to forward the message 
to the recipient. If recipient has no preference set or designates web delivery, then the 
forwarding engine 198 constructs an E-mail that includes a pointer to the message in the 
queue structure as described above. Alternatively, if an encryption/decryption protocol 
has been specified, the forwarding engine 198 can invoke the encryption service 189 to 
encrypt the message in accordance with the recipient's preference. Thereafter, the 
forwarding engine 198 can attach the encrypted message to an E-mail and forward the E- 
mail with attachments (if any) dnectiy to the intended recipient The processes invoked 
by the forwarding service 195 upon receipt of messages is described in greater detail 
below. 

The operational structiu^ of tiie forwarding service 195 is shown in Figure lb. 
Operationally, forwardmg service 195 includes plural layers including an origination layer 
50, a filter layer 193, a standard message format layer 52, an interoperability layer 54, a 
notify and store layer 56 and delivery layer 58. 

Origination layer 50 includes a front end (e.g., web front end 191 or E-mail 
application) that is configured to receive messages of various forms that are to be 
processed by the forwarding service. A message can be of the form of an E-mail message 
(received at one or more E-mail addresses associated with tiie forwarding service 195), a 
web form, a voicemail message, a fecsimile or other message with or without encryptioiL 
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services. In each of these scenarios, where a recipient preference is determined that 
includes direct forwarding to ihe recipient of a form of the message, the processing 
continues in the delivery layer 58, skipping the notify and store layer 56. 

The notify and store layer 56 is invoked when web (or other) deliveiy of the 
message is required. Web delivery can arise when a recipient has specifically requested 
web deUvery in accordance with a delivery preference stored in access list 199, or where 
no preference is defined. In the notify and store layer 56, a standard format message is 
securely stored in the queue structure 197 including tiie associated index to the entry. 
Thereafter, or concurrently, the recipient is notified by E-mail, facsimile, pager or other 
means as specified in the preference data for the recipient or in accordance with a default 
specification. In one implementation, the defeult mechanism selected for notice is an E- 
mail message. The notifying message includes a link to the message stored in the queue 
stmcture 197. In one implementation, the link is a hypertext (secure) link. 

The delivery layer 58 operates to deliver the message to the recipient. Delivery 
can be direct or through a web browser. The delivery preferences can specify delivery by 
web page, email, cellular telephone, &csimile, pager or other conmiunication means. For 
example, if the interoperability layer determines that the message is to be delivered in 
accordance with a particular encryption protocol, the delivery layer ensures that the 
protocol is applied and the encrypted message is attached to an E-mail wrapper and 
delivered directly to the recipient The delivery layer also includes a web fix>nt end for 
inter&cing with recipients to allow for the retrieval of messages stored in the queue 
structure 197. 

Operation 

Referring now to Figures la and 2a, an overview of a process for secure 
transmissions between a sender and a recipient over a network is shown. The process 
described below includes numerous process steps that can be performed at various 
locations of the computing system. The desaiption provided indicates a possible 
configuration for the computing system, and should not be construed as limiting. In the 
exanq>le shown, prior to sending or receiving secure E-mail messages, an initial 
(initialization) process is reqiured to be performed to generate public and private keys for 
the user (sender). The initialization process is described in greater detail in "Secure 
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as follows. 

Forwarding Service for Minimally Configured Recipients and Others 

Forwarding service 195 receives, at a minimuTn, each message to be forwarded to 
a recipient(s), processes the message including authentication of the sender, checking for 
recipient preferences or other public key data, securely stores the message in a queue 
(optional) and forwards an E-mail wrapper or other message to the recipient (41). If the 
recipient has designated an encryption/decryption delivery protocol preference, then the 
E-mail wr^per includes an encrypted form of the message (encrypted in accordance with 
the recipient's preferences) and can be opened unmediately by the recipient (40b). 

If the recipient is minimally configured or has designated a preference for web 
delivery, the E-mail wrapper includes a secure hyperlink that can be invoked by the user 
to link, using a web browser, to the web fi^ont end 191 of the forwarding service 195. The 
link includes a pointer to the particular message stored in the forwarding service's queue 
structure 197. In this scenario, the recipient (e.g. minimally configured recipient 1 04b) 
receives the E-mail wrapper, including hyperlink, through a conventional E-mail service 
(40c) or other means, such as pager, facsimile, or cell phone notification. The recipient 
can view the message by clicking on the hyperlink and invoking web browser application 
123 which in turns performs a series of operations to process and display the secure E- 
mail message, including attached files if any. The process includes linking to the web 
fixDnt end 191 associated with the forwarding service 195 and can include providing a 
RAPP. The forwarding service 195 processes received page requests for messages, 
verifies the RAPP (as appropriate) and returns a web page that includes the message from 
the sender (43). In one implementation, the connection between a recipient and the web 
front end 191 conforms with the SSL protocol for secure communications between 
devices. The processes invoked by each of the recipients (e.g., minimally configured 
recipients 104b) and the forwarding service 195 is described in greater detail below. In 
one implementation, designated recipients may receive tiie message via synthesized voice 
delivery over standard or cellular telephone connections following proper authorization. 

Fully Configured Recipients 

All fully configured recipients can receive the wrapper, including encrypted and 
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Send Process 

When a sender 102 desires to send a secure E-mail message to a tecipient 104, 
send process 248 is invoked by sender 102. As noted above, prior to sending of messages 
(or receipt by a fully configured recipient 104a) each user (sender 102 and fully 
configured recipient 104a) must perform initialization routine 247. As a reminder of this 
precondition. Figure 2b shows an initialization step in phantom. The ixiitialization routine 
is described in greater detail in "Secure Messaging System." 

Refraring to Figures la and 2b, send process 248 begins when vnapp&r application 
128 is invoked which in turn requires the user to designate one or more recipients (252). 
The body of the E-mail message is produced and any attachments are identified (254). In 
one inqjlementation. Has message, including any attachments, optionally can be 
compressed. A send message request is generated by sender 102 and transmitted to key 
server 108 (258). The send message request includes the E-mail address (or hash of the 
E-mail address) of the recipient, the E-mail address (or hash of the E-mail address) of the 
sender, the public key ID of the sender, and the hash of the message to be sent The 
request can itself be encoded, by first retrieving the pubUc key for the server. The public 
key can then be used in encrypting the request message in order to secure the link between 
the sender and the recipient. When an identical message is to be broadcast to multiple 
recq>ients, the request can include ihc E-mail addresses (or hashes) of multiple recipients. 
Thereafter, tiie process waits for a response fiom key server 1 08 (259). 

Assuming the recipient's E-mail address (or hash) is valid and locatable in the key 
server's key list and the key status is active, a time stamp certificate is received along with 
the public key(s) for the recipients that could be located (260). Thereafter the process 
continues in parallel along two paths. For each recipient who had a key that could be 
located, an encrypted message is created and sent directly to the recipient, unless the 
recipient has specifically indicated a preference to the contrary by setting a flag in the 
corresponding key status (stored in the key status list 209). When the key server sees such 
a preference flag, the key server can treat the public key as un-locatable. A fully 
configured recipient can turn on or off this preference flag using messages signed by the 
correspondmg key and sent to tiie key server 1 08. The process for recipients with 
locatable pubUc keys is described starting at step 261 . For all recipients whose public key 
was determined to be invalid or otherwise un-locatable, a forwarding process is invoked 
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starting at step 255. The details of the forwarding process are described in greater detail 
below. 



Sending Secure messages directly to a Recipient 

Continuingalongthepathtostep261.thetimestampcertificateisverified. The 
tune stamp certificate serves several purposes, incl^liijg: 1) establish that the message 
was sent from the sender to the recipient; 2) certify the time the message was sen^ 3) 
authenticatetherecipient'sandthesender'spublickeys; 4) certify the status of these 
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keys could not be located. The process includes creating a message (including header and 
body) that is addressed to the forwarding service (302). In one implementation, the 
forwarding service 105 siqjports plural sender types (e.g., ZixMail, X.509, PGP, HTTP 
post, web form, regular E-mail). The addressing of each message received by the secure 
forwarding service 195 can include an identifier for each sender type. For example, 
messages firom a ZixMail cUent can be addressed to ZixMail@secure-forwardinpr> 
service.com. 

After the message is addressed, the message header (304) and body (306) are 
populated. The message header or the message body includes extra fields to indicate the 
actual recipients of the secure message as designated by Hxe sender. These extra fields, 
however, will not be displayed to the recipient when the message is rendered. The header 
can include ofher data including authorization data (e.g., a SAPP). Authorization data can 
be used to verify that the sender is aufliorized to use the forwarding service 195. The use 
of authorization data is described in greater detail below. The body includes the message 
generated by the sender and can include the original sender message, attachments, and 
authentication data for authenticating the sender. 

As described above, even when a recipient's public key is unable to be located by 
the key server, a time stamp certificate is returned to the sender. Here the time stamp 
certificate serves several purposes, including: 1) establish that the message was sent by 
the sender via the forwarding service; 2) certify the time the message was sent; 3) 
authenticate the forwardmg service's and the sender's public keys; 4) certify the status of 
these keys at the tune the message was sent; and 5) validate the integrity of the associated 
message. In one implementation, the public key of the forwarding service is returned to 
the smder vdienever any recipient's keys are unable to be located. The public key of the 
forwarding service is used to securely transmit the message to the forwarding service. 
Alternatively, the public key of the forwarding service can be separately requested, 
embedded in the sender's client application 102, or oth^ivise discovered (as shown in 
phantom step 307 of Figure 2c). 

The time stamp certificate is verified (308) and then attached to the message, 
formmg data (310). The time stamp certificate produced and signed hy hsy server 108 
cannot be altered or attached to another message without detection. The inclusion of the 
key server certificate in the time stamp certificate ensures that the SMver' s public key is 
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message, flie TSC and the signature status is displayed (296). Theieafier, the process 
ends. 

View by a Minimally Configured Recipient 

View process 251 for minimaUy configured recipients 104b (Figure 2e) includes 
numerous steps. View process 251 begins with the receipt of the wrapper including 
hyperlink to the message (320). The wrapper is sent to the recipient using the recipient's 
E-mail address and arrives at the recipient's E-mail mailbox. Alternatively, tiie 
notification could be sent by ceU phone, pager, fecsunile or other notification method. 
The wrapper is opened using the recipient's conventional E-mail application (CCMail, 
Outlook and the like) and the hyperlink contamed therein is mvoked (cUcked) which in 
turn launches the browser application to establish a SSL connection with the server 
associated with the forwarding service 195 (322). More specificaUy, the recipient cUcks 
or double clicks on the hyperlink to invoke web browser 123 to retrieve a web page fi^om 
the forwarding service tbat includes the message from the sender. Optionally, the 
forwarding server may require the recipient to provide an authorization pass phrase (i.e., a 
RAPP) to the server associated with the forwarding service 195 before sending the web 
page (324). If the authorization pass phrase is correct, the mimmally configured recipient 
1 04b receives via an encrypted communication, such as through the SSL link, the HTML 
content (a page, e^ HTML, XML nmdering mstructions or the like) to be displayed in 
the browser (326). Thereafter, the minimaUy configured recipient can display the page 
(328). 

The page can include authentication data (optional), message data and 
attachments, if any. The user can view the authentication data provided by the 
forwarding server. The forwarding server obtains the authentication data by conducting 
verification steps similar to the verification steps used by a fidly configured recipient to 
vaUdate the message. For example, the authentication data can include a certificate of 
autiienticity generated/verified by the forwarding service as to the authenticity of the 
sender. The view process may conclude at tiiis pomt, or the user may invoke one or more 
other actions including return reply, storage or printing of the message (330). Thereafter, 
the process ends. 

The send and receive processes described above include numerous process steps. 
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notificaticm messages, will not reveal the identity of the sender to any outsider. Only the 
recipient can find out vAio the sender is when the message is viewed. 

If the SAPP is provided, the forwarding servw will check if the SAP? agrees with 
tile stored SAPP data. In one implementation, the message sent using a SAPP can be 
authenticated by attaching a Message Authentication Code (MAC). For example, 
attaching HASH( SAPP + HASH( SAPP + Message)) to the message will provide such an 
authentication and will protect the integrity of the message. If the SAPP agrees and the 
MAC matches, tiie delivery is allowed. 

If the sender/server connection is occurring in a non-interactive mode, and if a 
correct SAPP is not received (either the sender has forgotten their SAPP, or has not 
created a SAPP, or otherwise does not know the SAPP), the user is directed to create or 
re-create an authorization pass phrase. If the sender wants to create a SAPP (348), the 
process continues by aUowing the user to create a SAPP (352). In one implementation, a 
link to a website where the user can create an authorization phrase is executed. The 
process for creating an authorization pass phrase, either SAPP or RAPP, is described in 
greater detail in Figure 2g. Once a SAPP is created, the process continues back at step 
(340). 

Referring now to Figure 2g, a process for creating an authorization pass phrase 
begins by displaying a web page that requests a user to enter an E-mail address and an 
authorization pass phrase (either SAPP or RAPP or both) (360). Upon receipt of the E- 
mail address and authorization phrase (361), a confirming E-mail message is sent to the 
user (362). The E-mail pronqrts the user to send a confirmation message to the 
forwarding service. The forwarding service receives the confirmation (364) and 
"activates" user's E-mail address including storing the authorization pass phrase ( RAPP/ 
SAPP) in a respective location in the access list 199 in an entry associated with the user 
(366). Thereafter the respective send or receive process continues as described in 
association with Figures 2f and 2h, respectively. 

In one implementation, the SAPP and RAPP are not directly stored. Instead, a 
combination of a 128 bit "salf and a HASH (passphiase + emaU address + salt) is stored 
on the forwarding server. Each user has a different salt In this v««y, even if the database 
file that contains the SAPP and RAPP information is stolen, one is still required to mount 
a brute force (dictionary) attack to find each passphrase. 
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Key Server Processes 

Key server 108 (Figure 1) includes 
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transmission of secure E*mail messages. The operation of key server 108 is described in 
greater detail in ^Secure Messaging System.'* 

Recipient Process 

The process for viewing a secure E-mail message is described above and shown in 
Figures 2d and 2e. The process can include verifying tiie sender's and the server's 
signatures, verifying the audienticity of the server's public key and retrieving tiie status of 
the sender's public key. Authentication data (e.g., the status of tiie sender's public key) is 
displayed along with the contents of the secure message by viewer 130 or web browser 
123 (Figure la). 

The process for receiving a secure message by a minimally configured recipient is 
described above and shown in Figure 2e. Step 324 specifies when a RAFP is sent to the 
forwarding service. A user (recipient) that desires to make use of the forwarding service 
195 may be required to create a RAPP. The RAPP can be a unique pass phrase. A 
process 324 for providing a pass phrase to the forwarding service 195 including creating a 
RAPP is shown in Figure 2h and begins aft^ the forwarding service receives a message 
for web or oth^ delivery to the recipient The forwarding service determines if Ae 
recipient has a RAPP (370). If not, then the recipient is prompted to create a RAPP (372). 
In one implementation, the recipient is directed to a web site that includes instructions for 
creating an authorization pass phrase. The process for creating a RAPP is described 
above and shown in Figure 2g. If the recipient has a RAPP, then the user is prompted to 
provide the RAPP (374). The RAPP provided by the recipient is checked to determine if 
it matches the data on file (e.g., the RAPP or SAPP stored in the access list 199) (376). If 
no match is detected, the recipient may be prompted to try again (378). In one 
implementation, the user is limited to three incorrect attempts before he/she is prevented 
&om retrieving the message. Assuming the RAPP is correct, the process for displaying 
and viewing the message is continued startmg at step 326 of Figure 2e. In one 
implemeffiatfon, a SAPP may be used in lieu of a: RAPP to vieiw a message. ^ 

A user inter&ce presented by the viewer application is shown in Figure 4a. Fields, 
similar to tiie fields presented by the wrapping application user inter&ce, display various 
portions of the secure E-mail contents after decryption. Buttons are included for opming 
a message 902, replying to a message 904, replying to all recipients 906, forwarding a 
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message 908, clearing a messace 91 0 anH « • *• 

g a message 91 0, and pnnting a message 912. In addition, a seri^ «f 

^su.m.cato.900.ep..dedto^^ 

PK>cess. ^onem.plementation,onearmareofthetl«evisualindicato«900 
^ummate4asdescribedbelow.inacco„l««.^^ 

server 108 (Figure la). The status inWation ictun^ JT 

retrieval server 180^ of p- ^^°°"*™^^°»^ey server 108 (or key 

mevalserverl80)offig„«laincl«iesvalidtimeanddate(s)914 H^eti^.c. 
recovered from the decrvDtedm«..„^ u • '^s;yi4. Hie tmie stamp 

^^"^'''^P«*»««^c°aparedtothestatusinfoimation 
One or more indicators that loftir««,;i * "««s mioimation. 

«iuiwuoi5matiooJcsmulartoatrafficliehtornth*.r ^ • 

areillmninatedd«,endim^onth«.^ • ^ '^^'^^B in^cator 

^^endmgonthecompansonresults. Combinations can include- 

key server is not functionina nrTST^^ • ^ ^ **** connection to 

"»«Mge 9IZ L, addition, a seri« of ■ . ' 

authentication data. «««^s; yi4 as well as 

Forwarding Proxy (HTTP Post) 

Referring to Figure la. wrapping ^Mcation 128 can send secure E 
dnectly, or a conventional E-mail system «.nK. . J=™ secure E-mail messages 

messages (as part of an atta.1, ^ of the 

^ ^"^°^«»««»^««toaconventionalE.maUmessa.e.Hl^,„..... 
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recipient or fhrough a forwarding service. While one implementation of the invention 
requires the client sender to have access to a SMTP server, an alternative implementation 
provides a method for easy transmission when no SMTP server is accessible. Wrapping 
application 128 can invoke HTTP post application 124 to send the secure message with an 
HTTP post. Transmission by HTTP post is described in greater detail in "Secure 
Messaging System." 

Alternative Implementations 

The forwarding service 195 of Figure la can be used to forward messages from a 
plurality of different sender types. Referring to Figure 5, an alternative implementation of 
a secure forwarding service 195 is shown. Messages from any number of types of senders 
102 are addressed and transmitted to the forwarding service 195 using conventional or 
other transmission means. The conventional transmission means can include an E-mail, a 
web form or other form of post. Each message is processed by the forwarding service 195 
and stored in the queue structure 197. A user interface presented by the web browser for 
sending messages is shown in Figure 4b. Fields, similar to the fields presented by the 
wrapping application user interface (Figure 3a), allow the user to enter various portions of 
the message content, passphrase, attachments and other selections. 

Forwarding service 195 processes each message including providing parsing, 
decryption, authentication and other services. Filter layer 193 processes each message to 
produce a standard format message that is stored in the queue stmcture 197. The standard 
format includes a standardized authentication block 502 and a message block 504. 

The processing performed by filter layer 193 is uniquely determined by the type of 
message received. For example, filter layer 193 can include an application specific 
decryption and authentication routine for ZixMail messages. In this example, a 
decryption algorithm using a private key of the forwarding service extracts the original 
message and a sender signature. Thereafter, an authentication routine is used to verify the 
authenticity of the sender in accordance with the ZixMail secure messaging system 
described in "Secure Messaging System." 

Alternatively, other deoTption algorithms or authentication routines can be 
invoked in the filter layer 193. The particular processes invoked depend on the format of 
the message received At a minimimi, parsing services are provided to extract sender and 
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luae an enciypted message (encrypted in accoidance with nsciniVnt 7^ 

^^.^ ^ message ind^ an .«h„n^„ „^ rZ'., Z 
to the sender's E-mail address Thefil,-. '^'""^(SAPP) that is linked 
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include creating a message to be transferred to a recipient (usii^ the forwarding service 
195), addressing the message to the forwarding service, including a recipient address and 
authorization data in the message and sending the message to the forwarding service 195. 

The forwarding service 195 invokes the particular filter unit associated with the 
message type to parse, decrypt and au&enticate the received message. No matter the 
form, each message generaUy includes header information and message data. The header 
information includes, at a minimum, sender information and a recipient address. In one 
implementation, the sender information includes the sender's address and a sender 
identifier (S APP) that can be used to verify the sender is authorized to use the forwarding 
service 195. In addition, the header may include other information or service designators 
for one or more services to be invoked by the filter layer 193. For example, the header 
may include authorization data for the sender (SAP?), a request for a return receipt, a 
request for anonymous forwarding of the message (anonymizing the "fi-om" field in tiie 
message sent to recipient) and other informatioiL The message also can include a 
message body and attachments. 

Alternatively, the sender can be a conventional E-mail user 102d or a web-form 
user 102e (where a message is constructed as part of a form presented on a web page and 
subsequentiy submitted to the forwarding service 195 as response data). That is, the 
message need not be sent by a secure messaging sender, and can be provided through 
conventional meaiis directiy to the forwarding service 195. While the security level of 
these communications may be lower than that provided using a secure messaging sender, 
the forwarding service 195 can still provide an extra measure of security (i.e., using the 
SSL protocol) for these "non secure messages". In addition, the sender can be required to 
have an authorization pass phrase (SAPP) set up with the forwarding service 195 as 
described in fiirtfaer detail above. Examples of other senders 102 can include an HTTP 
Post application 102f, a facsimile device 102g, a messaging device (e.g., a cellular 
telephone or pager) 102h, or other digital or analog device (PDA or the like). One or 
more of these devi ces may be coupled via a gateway to the ne^A^ork 106 (e.g., Internet). 

No matter the sender type, the message generated by the sender 102 must be . 
properly addressed (to the forwarding service and include any type indicator for invoking 
any special processing in the filter layer 193), must include a recipient designator (ei&er 
in the head^, message body or in the address) and include iq>propriate identifying d flta 
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pass phrase/preference data pairing indexed by E-mail address (E-mail, RAPP, SAP?, and 
preference data) can be stored in access list 199 and checked to ensure that flie recipient is 
the authorized to retrieve the message. Assuming that fee authorization pass phrase 
(RAPP) is correct, forwarding service 195 retrieves the standard format message from the 
secure queue stracture 197 using the index information provided in the page request 
(616). Thereafter, the page is decrypted, returned to the recipient and then loaded for 
display by the recipient computer's web browser (618). 

The common filtering (using filter layer 193) and storage format (standard 
message format) allows for alternate branding of fee services provided by the secure 
forwarding service. For example. Brand X company can advertise secure forwarding 
services using its own company brand name. The brand name can be used as the message 
type identifier when forwardmg messages to the secure forwarding service. The brand 
can be a pointer to a particular message type including a secure message format In this 
way, all client messages can be delivered under the client brand using the central services 
of the forwarding service. 

The architecture for forwarding services includes a generic forwarding mechanism 
that can be configured to support new or changing messaging services. Only the front end 
filtering operations are required to be added/updated when adding a new message type, 
the remaining architecture and processes are imafiFected by a new (updated) content 
provider. The standard message format, which may also be branded, is used for delivery 
of all messages via browsers to recipients. 

In one implementation, each time a message is retrieved from the forwarding 
service a receipt can be generated that can be returned to or picked up by the sender. That 
is, the sender can specify a return receipt be generated by the forwarding service 195 and 
stored for future pick up or immediate delivery to the sender. Forwarding engine 198 can 
be configured to forward return receipts to the sender. The receipt can be used to indicate 
that the message was retrieved by the recipient. 

In one implementation, messages can be forwarded with carbon copies (cc) sent to 
Ae sender and blind carbon copies (bed) sent to the other designated parties. The process 
for sending a message to each recipient (a cc or a bcc recipient) is tiie same as described 
above 

While this invention has been described in terms of several preferred 
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WHAT IS CLAIMED: 

1 . A system for providing secure E-mail services comprising: 
a forwarding service operable to 

receive an E-mail message for delivery to a recipient; 

store the message atleast temporarily in a storage means; 

check for recipient preferences for delivery of the E-mail message content; 

if no preference is specified and if Web-based delivery is specified, 

provide an E-mail notification to the recipiCTt including a secure link to the 

message, and 

respond to a page request from the recipient indicating the message 
including extracting the message fix>m the storage means, formatting the message as a 
page and delivering the page to the recipient's web browser; and 

if a preference for delivery other than Web-based is specified, deliver the 
message in accordance with the recipient's preference. 
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